Release 10.1A: OpenEdge Development:
Progress Dynamics Administration

Using SDOs kept alive on the server

When you evaluate whether to deploy SDOs to stay alive on the server, consider these guidelines:

Once started, an SDO remains in memory until the host process is terminated. This effectively means that to clear SDOs, you must either trim agents or stop and restart the broker. This applies to both AppServer and WebSpeed agents.
Because each client request can be directed to a different agent, the same SDO will most probably be started and remain in memory in multiple agents. Each such SDO takes up more server memory resources. However, each SDO memory footprint is relatively small.
When processing a client request, if a required SDO is in memory (as determined by its LogicalObjectName), the server re-uses it regardless of the DestroyStateless property value. This property is only used to decide the fate of the SDO upon request completion.
Although you can set DestroyStateless at the instance level, a kept-alive SDO has no knowledge of the particular instance that starts it. An SDO is only recognizable and retrievable by its LogicalObjectName. So, many kept-alive SDOs can be started after setting this property for a single instance.
The most time-consuming task when starting an SDO is setting up any required dynamic elements such as dynamic queries, dynamic RowObject and RowObjUpd tables, dynamic buffers, and so on. Therefore, dynamic SDOs benefit the most from being kept alive, especially those with many fields.
Datasets created as part of a client request are destroyed upon request completion. However, custom data structures that are created, such as temp-tables, remain as part of the SDO. To change this behavior, you can override destroyObject in the SDO (or its DataLogic procedure, if one is used) to specify any custom cleanup between requests.